1. Field of the Invention
The present invention provides a system and method for testing a centralized system used to manage network restoration in the event of failure. Specifically, the present invention provides a system and method for segmenting the functions of a network emulator emulating an actual network, by separately receiving and managing information about an event (i.e., a failure) and the nature of the event (i.e., the type of failure).
2. Related Art
A telecommunications network is used to provide numerous services to customers. All users of a network benefit from a quality restoration system. A restoration system is a system that restores service to customers in the event of a network failure.
MCI Telecommunications Corporation, and most other telecommunications service providers, utilize a common transmission network. This transmission network is served by a common restoration system, which has a centralized system responsible for management of the network.
When a connection between two nodes in the network is disconnected, one or more alarms will be received by this centralized system. This centralized system is responsible for monitoring, restoration, and control of the network. A trunk, which provides a given bandwidth of connection capacity, can traverse several nodes. One or more trunks can be physically collocated between two nodes. It is, therefore, possible that a cut in connection between a first node and a second node will generate alarms from several nodes, because several trunks (e.g., fibers) can be disconnected simultaneously.
The nature of the cut in connection can vary. For example, an ax cutting through a trunk may cause simultaneous disconnection of the trunks, and consequently simultaneous generation of alarms at each of the nodes for transmittal to the centralized system. Conversely, it is possible that the alarms will not be detected simultaneously. For example, a fire or an animal gnawing through a trunk can cause sequential disconnections, with each disconnection generating a different set of alarms. As another example, when fiber optic cables are exposed to freezing conditions, the fibers may freeze or thaw in atypical patterns, causing alarms to be generated in a bizarre pattern.
The response of the centralized system can vary. As one example, the response may be to report the alarms to someone, to consolidate the alarms and indicate the location of the failure. As another example, the response may be to consolidate the alarms, isolate the failure, generate a restoral route, and issue commands to other devices in the network to shift the traffic (i.e., to get it away from the failure point). This latter restoration of network function is typically a preferred response.
All services of the telecommunications services provider are enhanced by the successful operation of the restoration system, particularly the successful operation (i.e., including speed and accuracy) of the centralized system. This requires that the centralized system be thoroughly tested throughout its continuous development life cycle.
Certain types of nodes, namely nodes that are switching devices, are used to provide restoration capability. In the event of a network outage, these devices re-route impacted traffic to circumvent the outage, using spare network capacity. One such device is a Digital Cross-Connect for DS-3 trunks (DXC 3/3). The devices and interconnecting network capacity that are used for restoring traffic are collectively referred to as a restoration network.
The restoration network employs the centralized system to restore network function. Typically, the centralized system is a computer system that is connected to each device, or node, in the restoration network, performing many functions, such as the mentioned functions of monitoring the restoration network, performing restoration analysis in the event of an outage, and controlling the restoration network to produce a restoration of traffic.
The centralized system, itself, is typically subject to continual improvements. In addition to the initial roll-out of the centralized system, the telecommunications service provider typically introduces several versions each year. These versions include new features and capabilities, as well as fixes to software defects, and comprise complex software. As with any complex software system, the centralized system requires extensive testing. In addition to testing the functionality of the centralized system, stress testing is also required to test the centralized system's behavior in a real-world environment.
It is impractical, and sometimes impossible, to use the actual restoration network for testing the centralized system due to the intrusion to live traffic that it would cause. Testing in a non-production, test environment is needed. It is cost-prohibitive, however, to duplicate the actual network in the test environment. This requires extensive time, effort, and physical resources, since a typical restoration network may consist of hundreds of DXC 3/3 nodes, each with multiple links to the centralized system.
To solve this problem, network emulators have been created. As the name implies, network emulators emulate the behavior of the actual network. Network emulators are typically computer programs that run on a single computer. By connecting an emulator to a centralized system that is to be tested, the centralized system can be observed to behave as it would when placed in a real network environment.
Unfortunately, known network emulators that are currently capable of emulating an entire network use a monolithic process architecture. The processes of emulating communications links, creating and formatting messages, processing messages, analyzing topology to determine alarm generation, and sequencing alarms, are primarily performed simultaneously. Even though these different functions are realized by discrete software components, during emulation each function is performed simultaneously and must compete for the computing resources of the centralized system.
The design of these known emulators reflects the design of an actual network device. Under operation, the emulator must perform the process of an emulated device repeatedly, hundreds of times in succession. This results in limited performance. While one component of the known emulator is sending alarm messages to the centralized system under test (i.e., the centralized system being tested by the network emulator), another component is analyzing data to determine which alarms to send, and another component is formatting alarm messages. All of these events typically occur simultaneously, using the same CPU and RAM.
Known emulators are also difficult to develop and maintain. Since the software architecture is not segmented by the processes performed, adding or modifying a process requires extensive analysis of software code.